SOFTWARE PAY-PER-USE PRICING 



1 Technical Field 

2 The technical field is in intelligent collection and monitoring of software metrics 

3 in a multi-computer environment with a plurality of software packages. 

4 Background 

5 Traditional models for acquisition, use, and payment of software require a 



6 customer to pay for an expected number, or instances, of a software product that is 

7 intended to operate on the customer's computer network or system. For example, a 

8 customer desiring to provide a word processing software product for use by the 

9 customer's employees will generally pay for one copy of the software product for each of 
1 0 the customer's employees that will use the software product. Such payment may give the 



1 1 customer a license to use the software product at each of the employee work stations. 

1 2 The license typically prohibits copying and further distribution of the software product to 

13 other employees of the customer. The customer, moreover, pays a full price for each 

14 license thus obtained. 

15 However, some or all of the customer's employees may use the software product 

16 only on a part-time basis. Thus, the customer in effect pays for excess capacity to ensure 

17 all of the customer's desired employees have access to the software product. As an 

1 8 alternative, the customer could acquire a limited number of software product licenses. In 

1 9 this alternate arrangement, some customer employees may not be able to use the software 

20 product when needed or desired, thereby reducing the work output of the customer. 

21 Finally, the customer's hardware needs may change rapidly. Acquisition or 



22 disposal of hardware may affect the number of software licenses the customer needs to 

23 have in place. By having to separately purchase additional licenses of the software 

24 product, the customer may experience delays before the newly acquired hardware is fully 

25 functional. 

26 Summary 



27 A pay-per-use (PPU) approach could apply to the pricing and leasing of large- 

28 scale software products. In a traditional purchase model, some software products also 

29 require a large capital outlay for their purchase, depending on the size of the software 

30 products and the use of the software products. Such software products pose technical and 

3 1 logistical obstacles to being priced using a PPU approach. Different software vendors 

32 may develop software products without a standard method for collecting or transmitting 
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1 software usage/metrics data. Different software vendors may want to collect different 

2 metrics such as number of users or central processing unit (CPU) utilization. Each 

3 computer could have multiple different PPU software products to meter and monitor, 

4 thereby increasing the complexity of any software PPU approach. 

5 Current software manufacturers may issue licenses that are limited to a fixed 



6 number of users, operators or other metrics. Such licenses may not reflect the changing 

7 needs of the customer, requiring further interaction between the software vendor and the 

8 customer. For example, a customer who has already purchased a ten-user license cannot 

9 add an eleventh user instantly without having to go back to the vendor for more licenses. 

10 Neither can the customer instantly reduce costs by switching to a 5-user license if 

1 1 customer needs so dictate. 

12 The PPU approach includes a software metering system and method that solves 
a 1 3 these problems by providing a way for reliably measuring and billing for software 

y 14 product usage while allowing each PPU software vendor to measure and bill based on the 

111 1 5 metrics that are appropriate for that PPU software vendor. The software metering system 

jf 16 includes a computer with a PPU software product, where metrics data may be collected 

m 17 fj- om the PPU software product and where the metrics data may be transmitted to a 

Q 18 remote location. 

[T 19 Description Of The Drawings 



Uj 20 The detailed description will refer to the following drawings, wherein like 

fij 21 numerals refer to like elements, and wherein: 

22 Figure 1 is an overview of a pay-per-use (PPU) software metering system 

23 according to one embodiment; 

24 Figure 2 illustrates different components of a software metering system according 

25 to one embodiment; and 

26 Figure 3 is a flowchart illustrating one embodiment by which the process by 

27 which software metering data is collected. 

28 Detailed Description 

29 Figure 1 is block diagram of a pay-per-use (PPU) system 10 that allows flexible 

30 dynamic pricing of products 30i. In an embodiment the products 30i may be PPU 

31 software products installed on a computer 18 at a customer site 13. The flexible pricing 

32 of the products 30i is supported by collecting metrics (or usage) data from the products 

33 30i and transmitting metrics data over an external network connection 14 to a remote 

34 location 16, which may incorporate mechanisms for billing and payment collection. 
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1 The customer site 13 may include mechanisms for monitoring, collecting, pre- 

2 processing and transmitting the metrics data. In an embodiment, some or all of the 

3 mechanisms may be incorporated into the products 30i. In an alternate embodiment, 

4 separate devices (not shown) may be included at the customer site 13 for completing the 

5 functions of monitoring, collecting, pre-processing and transmitting the metrics data. 

6 Figure 2 is a detailed block diagram of a software PPU system 1 00. The customer 

7 site 1 3 may include a computer 1 8 with at least one PPU software product 30. The 

8 computer 1 8 may include a software metering agent 20 and/or a metric gathering tool 25 

9 for performing the collection and monitoring functions. The customer site 13 may 

10 include a utility metering appliance connected to the computer 1 8 for collecting and 

1 1 transmitting metrics data through the external network connection 14. The vendor site 
S 12 16 may include a usage collection and billing system 40. The vendor site 1 6 or a third 

O 13 party vendor site (not shown) may further include a billing computer 45 and a web portal 

4= 

m 14 50. 

'g 15 The utility metering appliance 15 may govern collection of software metrics data 

=0 16 for an internal network on the customer site 13. The utility metering appliance 15 itself 

p 17 may not directly collect metrics data from each PPU software product 30 on the internal 

f7 1 8 network, but rather may rely on mechanisms such as the software metering agent 20, 

1 Un 19 which is a software program that resides on each computer 18 (or each instance of the 

ij 20 operating system in computers running multiple instances of the operating system). The 

21 software metering agent 20, in turn, receives metrics data from at least one, and often 

22 more than one, metric gathering tool 25. The metric gathering tool 25 may be provided 

23 by the PPU software product vendor or another vendor, and may be responsible for the 

24 collection of metrics data from each PPU software product 30. 

25 The utility metering appliance 15 itself may run as a process on another computer, 

26 including one of the computers 1 8 running PPU software products 30, but for network 

27 efficiency, the utility metering appliance 1 5 may be implemented on a standalone 

28 computer, or on a server that is used for similar administrative tasks. The utility metering 

29 appliance 1 5 may be implemented as a component device in a rack mountable system, or 

30 as software running on a rack mountable system, or may be implemented on a completely 

3 1 separate computer system. The utility metering appliance 15 is not resource-intensive 

32 and may generally be run on a less powerful computer. 

33 The customer site 13 may have multiple computers 18, each of which has the 

34 software metering agent 20 for collecting PPU metrics data from the PPU software 
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1 products 30 residing on that computer 18. The utility metering appliance 1 5 may 

2 communicate with the software metering agent 20 through a network management 

3 protocol such as Simple Network Management Protocol (SNMP) or Web-Based 

4 Enterprise Management (WBEM) protocol, both of which allow polling of information. 

5 The utility metering appliance 15 and software metering agent 20 also can communicate 

6 using the similar Desktop Management Interface (DMI), a framework for network 

7 management. The utility metering appliance 15 and the software metering agent 20 may 

8 also communicate and transmit data using protocols that are not specifically dedicated to 

9 network management, such as Hypertext Transport Protocol (HTTP) or Secure HTTP 

10 (HTTP/S), provided that the utility metering appliance 15 can effectively communicate 

1 1 data to and from the software metering agent 20 using the particular network protocol. 

12 The exact implementation of the software metering agent 20 will depend on the 

13 particular communication protocol being used. In an SNMP implementation, the 

14 software metering agent 20 is implemented as an SNMP agent or subagent. If 

1 5 WBEM/DMI is the communication protocol, a WBEM/DMI data provider serves as the 

16 software metering agent 20. A common gateway interface (CGI) program accessible to a 

1 7 web server could be used as the software metering agent 20 if HTTP or HTTP/S is used 

1 8 as the communication protocol. The collection function of the metric gathering tool 25 

1 9 may also be performed directly by the software metering agent 20. 

20 The software metering agent 20 may be part of the'operating system of the 

21 computer 18 and may include a registry 35 that contains information about the PPU 

22 software products 30 running on that computer 1 8 (or instance of the operating system). 

23 The registry 35 may be a flat-file database containing the names of all of the PPU 

24 software products 30 as well as the pathname of the metric gathering tool 25 associated 

25 with each PPU software product 30. The software metering agent 20 reads the registry 35 

26 in order to access the metric gathering tool 25 so that the metering agent 20 can collect 

27 the necessary metrics data. 

28 Metrics data returned by the software metering agent 20 may use a standardized 

29 data structure such as one specified by a management information base (MIB) for SNMP 

30 or by the Managed Object Format (MOF) for WBEM. In a SNMP implementation, for 

3 1 example, the MIB can be specified for returning certain data such as the name of the 

32 software, an array of variable names, and their values. The MIB would then be compiled 

33 into a data structure and downloaded to the software metering agent 20 (implemented, for 

34 example, as a SNMP subagent) where the data structure would be used in collecting data. 
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1 Other data structures may be used to implement the transfer of data between the software 

2 metering agent 20 and the utility metering appliance 15. 

3 The metric gathering tool 25 may be an executable command or an executable 

4 script that gathers software metrics data for the PPU product 30 or, if the metric gathering 

5 tool 25 is also acting as software metering agent 20, an SNMP agent or other data 

6 provider. The PPU software product vendor or another vendor may be responsible for 

7 developing or customizing the metric gathering tool 25 to suit its software product in the 

8 development of the PPU software product 30. For example, some conventional software 

9 products inherently gather some types of metrics data that can be extracted by a properly 

10 configured metrics gathering tool 25. In another example, a conventional software 

1 1 product may need to be modified to make the conventional software product operable 

12 with metrics data. In this case, the conventional software product is PPU-enabled by 

1 3 either integrating the metric gathering tool 25 into the software product or modifying the 

14 software and the independent metric gathering tool so that the software product and the 

15 metric gathering tool cooperatively provide the desired metrics data. The particular 

1 6 metrics being gathered depend on the PPU software product 30 being used and the 

1 7 particular business model for charging for software usage. One type of metric that may 

18 be collected by the metric gathering tool 25 is a snapshot metric, which represents a 

19 snapshot of the current state of the system. One common type of snapshot metric, for 

20 example, is the number of users using the PPU software product 30 at any given time. 

21 Cumulative metrics, which measure the total accumulated value of a given parameter, 

22 may also be collected by the metric gathering tool 25 such the number of transactions or 

23 the number of files being produced for a given pre-determined time interval. CPU 

24 utilization by the PPU software product 30, or execution time by the PPU software 

25 product 30 may also be collected. The metric gathering tool 25 may also collect metrics 

26 such as whether a PPU software product 30 was used at all, for licenses that depend on 

27 simply whether a product was used during a given period of time. Finally, the metric 

28 gathering tool 25 may collect I/O metrics such as number of I/O reads or writes for I/O- 

29 intensive PPU software products 30. 

30 Different types of PPU software products 30 may require different types of 

3 1 software metrics data. Moreover, different vendors may want to collect different types of 

32 software metrics data. Consequently, the vendor of any given PPU software product 30 

33 will generally control and specify what metrics are collected by the metric gathering tool 

34 25 as well as how the metrics are collected. For example, a first vendor may design the 
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1 metric gathering tool 25 to measure all or some of the following metrics specific to the 

2 PPU software product 30: the number of users, number of users of a given type, software 

3 license level, transactions processed per minute, total number of transactions processed, 

4 number of files created, sizes of those files created, number of keystrokes, number of 

5 times a specific software product feature has been accessed, number of managed nodes, 

6 or some other quantity representative of the value the user derives from the use of the 

7 PPU software product 30. On the other hand, a first or second vendor may design the 

8 metric gathering tool 25 to measure whether the PPU software product 30 is currently 

9 executing, the number of active CPUs on a system, the speed of those CPUs, the amount 

1 0 of memory in the system, the amount of wall clock time for which the PPU software 

1 1 product 30 has been executing, the cumulative CPU time for the PPU software product 30 

12 or some other quantity representative of the value the user derives from the use of the first 

1 3 vendor' s PPU software product 30. This latter list of metrics data types typically do not 

1 4 require in-depth knowledge of the function or internal operations of the PPU software 

15 product 30. 

1 6 The metric gathering tool 25 may return software metrics data in a specific pre- 

1 7 determined data interface, such as a colon-separated variable text format or rows of 

1 8 variable/value groups, that is compatible with the software metering agent 20. The 

1 9 software usage data may be in binary format but is more likely to be in text format. The 

20 system vendor could provide a developer kit to software vendors documenting the 

21 interface requirements for the metric gathering tool 25 and providing some source or 

22 object code for specifying commonly measured metrics data such as the ones listed above 

23 so that the software vendor may enable their software products for PPU. The developer's 

24 kit could also provide programming code for a generic metric gathering tool that the 

25 software vendor may customize to create a metric gathering tool 25 specific to the PPU 

26 software. The metric gathering tool 25, once it is completely developed, may then be 

27 packaged with both the PPU software product 30 and a control script or application that, 

28 when executed, will register the particular software product 30 with the software metering 

29 agent 20. 

30 Each software metering agent 20 gathers metrics data from the metric gathering 

3 1 tools 25 for all of the PPU software products 30 registered with that software metering 

32 agent 20, and transmits the collected software metrics data to the utility metering 

3 3 appliance 1 5 . The utility metering appliance 1 5 then periodically transmits the metrics 

34 data to a usage collection and billing system 40, possibly through a web server (not 
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1 shown). The usage collection and billing system 40 will typically be maintained and kept 

2 at a vendor location, and will often contain data for many customers. The usage 

3 collection and billing system 40 will then forward the software metrics data to at least one 

4 billing computer 45 for billing the customer. The system vendor for software applications 

5 would control the billing computer 45 for its own PPU software products, but other third- 

6 party software vendors could have separate billing computers 45 for billing the customer. 

7 The billing computer 45 may generate notifications based on business rules specified by 

8 the vendor of the PPU software product or another vendor. The notifications may be 

9 formal bills or may be reminders to the customer to submit payment. The web portal 50 

10 may also be used for providing user-friendly access for either the customers or the system 

1 1 vendor personnel to information based on data generated from the billing computer 45 

12 and from the usage collection and billing system 40. 

q 1 3 The PPU software product 3 0 may be configured for PPU usage by registering the 

5 14 metric gathering tool 25 for the PPU software product 30 with the software metering 

Ln 1 5 agent 20 on the computer 1 8 that is running the PPU software product 30. The PPU 

j= 1 6 software product vendor may provide a registration application or registration script that 

-D 1 7 links the software product 30 and its accompanying metric gathering tool 25 with the 

Q 1 8 software metering agent 20. The registration process may include executing the metric 

fj 1 9 gathering tool 25 to verify that the tool 25 correctly returns data to the software metering 

LH 20 agent 20. The PPU software product 30 is ready for metering PPU usage once the 

fy 21 registration process is completed. 

22 Referring to Fig. 3, one embodiment for collecting software metrics data from 

23 PPU software products 30 begins when the software metering agents 20 return metrics 

24 data to the utility metering appliance 1 5 at different intervals during the day. The utility 

25 metering appliance 15 may periodically poll the software metering agents 20 found on the 

26 network (step 200). Each software metering agent 20 may have its own polling interval 

27 as each agent 20 could conceivably regulate different types of PPU products. Each 

28 software metering agent 20 will then execute the metric gathering tools 25 linked in the 

29 registry 35 and collect the resulting software metrics data (step 210); the software metrics 

30 data may include information on transactions, CPU usage, or any metric that the PPU 

3 1 software product vendor deems to be pertinent in calculating usage. To expedite 

32 communications, the metric gathering tool 25 returns the software metrics data in a 

33 standardized format that can be read by the software metering agent 20 (step 220). 
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1 Alternately, the utility metering appliance 15 may rely on the software metering 

2 agents 20 to provide the data without polling. In this embodiment, the software metering 

3 agents 20 collect data from the metric gathering tools 25 at collection intervals and 

4 initiate communication with the utility metering appliance 15. The utility metering 

5 appliance 1 5 may be set to receive metrics data from the software metering agents 20. 

6 The utility metering appliance 15 and software metering agent 20 may also be combined 

7 so that the usage meter 1 5 calls the metric gathering tools 25 directly. 

8 The utility metering appliance 15 may collect metrics data from the software 

9 metering agents 20 several times per hour, depending on the type of metrics data that is 

10 being collected. For example, the utility metering appliance 15 may be set to collect data 

1 1 from the software metering agents every 20 minutes for a total of 72 intervals per day. 

12 Other collection intervals, however, may be specified depending on what type of software 

1 3 metrics data is being collected. Frequent collection is recommended for snapshot metrics; 

14 however, frequent polling would not be as critical (or recommended) for cumulative 

1 5 metrics. The utility metering appliance 1 5 may have a single collection interval in order 

16 to simplify collection. 

17 Alternately, vendors of the PPU software products 30 may be permitted to specify 

1 8 their own polling intervals for their software products. The software products 30 may 

1 9 communicate with the utility metering appliance 1 5 by embedding their specific polling 

20 intervals in a header sequence for the software metrics data. The utility metering 

21 appliance 15 would then read this polling interval from a header sequence found in the 

22 software metrics data transmitted by the metric gathering tool 25. Should multiple 

23 software products 30 on the same computer system have the same agent 20 but different 

24 polling intervals, the utility metering appliance 15 will choose the lowest polling interval 

25 among the software products 30. Multiple polling intervals, where different agents are 

26 polled at different intervals, may be possible in cases where the metric gathering tool 25 

27 also acts as a software metering agent 20. 

28 The software metering agent 20 gathers all the software metrics data obtained 

29 from the metric gathering tools 25 and transmits the data to the utility metering appliance 

30 15 through the network (step 230). The software metering agent 20 transmits the 

3 1 software metrics data, which are returned by the metric gathering tool 25, to the utility 

32 metering appliance 15 without interpreting or analyzing the data. However, the software 

33 metering agent 20 does parse the data to obtain parameters such as variable name and 
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1 value. The exact nature of the software metrics data gathered by the software metering 

2 agent 20 remains opaque to the agent 20. 

3 The utility metering appliance 1 5 stores all of the software metrics data received 

4 from the software metering agents 20, and periodically transmits the metrics data to the 

5 usage collection and billing system 40 located at the system vendor site for final 

6 collection and processing (step 240). The utility metering appliance 15 may package the 

7 data from a given periodic interval, compress the data, and transmit the data to the usage 

8 collection and billing system 40 via encrypted or otherwise secure transmission 

9 periodically. The usage collection and billing system 40 stores the software metrics data 

1 0 and performs further calculations and analysis of different metrics data received from the 

1 1 utility metering appliance 15. For some of the metrics data values, such as cumulative 

12 metrics, (which are added continuously over a time period) for example, the usage 

1 3 collection and billing system 40 will determine the initial and final value for a given 

14 parameter, as well as the difference between the two. The usage collection and billing 

1 5 system 40 may then forward the calculated metrics data value to at least one billing 

1 6 computer on a periodic basis (e.g. per month). 

1 7 Each billing computer 45 in turn analyzes the usage from the software metrics 

1 8 data and proceeds to apply business rules for each given PPU software product 30 in 

1 9 order to generate a bill that will be forwarded to the customer (step 260). The business 

20 rules are specified by the PPU software product vendor. Each billing computer 45 may 

2 1 reside with the vendor of the overall system 1 0 or with a PPU software product vendor, 

22 depending on how each PPU software product vendor wishes to bill its customers. The 

23 web portal 50, moreover, may also display the software metrics data (step 270), enabling 

24 the customer to track and monitor usage for the PPU product 30 in a user accessible form 

25 (step 280). The web portal 50 is served by the vendor site, typically as a web-based 

26 application, available through a public network such as the Internet. The web portal 50 

27 allows only customer or system vendor access through use of a password. 

28 While the invention has been described with reference to the embodiments 

29 thereof, it will be appreciated by those of ordinary skill in the art that various 

30 modifications can be made to the structure and function of the individual parts of the 

31 system without departing from the spirit and scope of the invention as a whole. 
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